Hi guys, Been getting issues with the version store running out of space (155Mb) on our Windows 2003 SP2 / Exchange 2003 Sp2 Server. I have put limits on mail delivery (10Mb) and have been reading articles about this problem: http://msexchangeteam.com/archive/2006/04/19/425722.aspx and http://msexchangeteam.com/archive/2008/05/23/448923.aspx This hotfix is included in SP2: http://support.microsoft.com/kb/815417 I want to find out what is casuing the issue based on the information in the 623 Application event ID. I found a blog using powershell but I am not sure how to get that function (get-loggedonuser) to work. "Information Store (5600) First Storage Group: The version store for this instance (0) has reached its maximum size of 155Mb. It is likely that a long-running transaction is preventing cleanup of the version store and causing it to build up in size. Updates will be rejected until the long-running transaction has been completely committed or rolled back. Possible long-running transaction: SessionId: 0xBD333AE0 Session-context: 0x00000000 Session-context ThreadId: 0x0000030C Cleanup: 1 " How do you work out the sessionID etc to a username? Thanks

Hi, If only sessionID is required you can get this info through start->run->tsadmin, if you need some other info do let us know.Ripu Daman Mina | MCSE 2003 & MCSA Messaging

Could be a number of things, backups, anti-virus, wayward client. Did you go through all the troubleshooting steps in the EHLO blog yet?

Hi Ripu, Thanks for your reply. However I am unable to see where I can marry up SessionId: 0xBD333AE0 with a session ID in tsadmin. Tsadmin will show is logged into the box - but I beleive it si a user doing a massive search / sending an email or some such thing.

HI AndyD_ I have modified the online defrags, message sending/receiving limits/backup times/AV scanner exclusions. It is only a recent phenomenon also, whci is odd. The server hasn't been patched in a few months however the patches that are required are secirity patches and nothing (I can see) that would relate to version store. I didn't want to change the msExchESEParamMaxVerPages registry key just yet, given it is sporadic (happened wednesday mid morning twice and then friday afternoon several times) I beleive it is a user doing something but not sure how to find out. We use SCOM 2007 R2 and it's alerts aren't that helpful (over and above what I have found in articles on the 'net)

If you suspect a client, you may want to install Exmon on the server and see if any mapi clients are pounding it.

It's just happened again. Backups are still running and I need to see what has happened or what someone is doing. Exmon doesn't give me the information I would expect to see. What would I be looking out for?

I think the only way I can truly diagnose this is if I do a dump of the store.exe. . . .

With Exmon, look for clients with high number of mapi sessions/requests. Backups can also cause this by the way. Are you doing mailbox level backups or regular storage group backups?

IS this the 'sessions' column under "By Clientmon" tab? users have 1 to 5 in this column. Backups are storage level

It's happened 3 times since the backup had completed this morning.

we use BES 4.0 also, wonder if this is an issue

You have confirmed the Jet integrity with ISINTEG, haven’t you? You have seen event 701 after the online maintenance, haven’t you? Have you run “Microsoft Exchange Server Performance Troubleshooting Analyzer Tool” for checking the performance? Have you increase the transaction log buffer as suggested in this article? You can send the adplush dump to CSS for investigation as suggested on the team blog Update: Please also check the number of item count in users’ mailboxes. Keep items in your critical folders, especially inbox down to 5,000 or less items. Larger folders can cause to the issue we are facing. PFDAVAdmin tool can be used to find the item count Using PFDAVAdmin to get the item count within the folders on mailboxes on an exchange server James Luo TechNet Subscriber Support (http://technet.microsoft.com/en-us/subscriptions/ms788697.aspx) If you have any feedback on our support, please contact tngfb@microsoft.com